home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 302 < prev    next >
Text File  |  1994-08-27  |  9KB  |  240 lines
  1. Subject: Digestive
  2. Date: Sun, 5 Jun 1994 23:20:48 +0200 (MDT)
  3. From: Annius.Groenink@cwi.nl (Annius Groenink)
  4. X-Face: "E3Hm]k]&:,OEP<{D2ixJf>-9[qOGLebNa0&cQyFL-a~)kTM3&&I"gFw=fJ]K%1IduGjOE`
  5.  ZGu]&~G]QNGa7i/L!+#Xng<|+}HKYHj~5?fTInUEUh0$I1gBI7jrA!&_|e/pR1[cX:^xgJTPsrjA_9
  6.  m8Zli[|.-u{]+c1(6C7mL*m`/_J\>.{4!:g
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10.  
  11. I discovered  'split' on my  UNIX box,   and managed  to sz  the 70K  of
  12. gem-list I received today home over the phone line.
  13.  
  14. ------------------------------------------------------------------------
  15.  
  16.    [> Perhaps we should do this:
  17.    [> 
  18.    [>     <-        Lshift
  19.    [>     ->        Rshift
  20.    [>         (uparrow)    Either shift
  21.  
  22.    Well, I do make a distinction in MasterBrowse (using exactly the method
  23.    outlined above) but upon reflection I think it would be better not to
  24.    make a distinction.  When typing, people ussually use the closest shift
  25.    key to the key they want to press, so forcing them to use one key or
  26.    the other might not be desirable.
  27.  
  28. I think we should include the option in the proposal with the additional
  29. note that it should  only be used  rarely and there  should be a  pretty
  30. good reason (for example something with left and right versions).
  31.  
  32. ---
  33.  
  34. Tim writes
  35.  
  36.    Initially, I thought that I might be able to tolerate looking at the 
  37.    scancode for the control-keys, but with all this extra CRAP that needs to 
  38.    be dealt with for foreign keyboards, my responce is 'screw it!'.  
  39.  
  40.    Hey, people, you're getting overly complicated!
  41.  
  42. This is a technical discussion,  Tim.  We're not afraid of details here,
  43. be they of psychological nature or whatever.  A demanding user (such  as
  44. yourself!) will not tolerate  a programmer  who doesn't go  to the  very
  45. extreme to make his/her creations perfect.
  46.  
  47. I don't have a foreign keyboard either :-)  [it's a UK type] but I still
  48. care (not least because Germany is a good Atari market).
  49.  
  50. ---
  51.  
  52. Andre, wittily,
  53.  
  54.    (timothy)
  55.  
  56.    > When the simple solution would be to change select-whole-document to
  57.    > something else on the keyboard... end of story. 
  58.  
  59.    If SHORTCUT.INF becomes a reality, you will be able to do exactly that.
  60.  
  61. ... except, probably,  in Atari Works...
  62.  
  63. ---
  64.  
  65. Timothy:
  66.  
  67.    What do you suggest that the programmer do to distinguish between, some 
  68.    control codes (like ctrl-m, i, h, etc.) and the other keys that normally 
  69.    generate them (return, tab, backspace, etc.), and maintain compatibility 
  70.    with foreign keyboards?  Keep a seperate key table for each language?
  71.  
  72. The keytbl() command gives you the key tables.  It produces different
  73. tables for different ROMs.
  74.  
  75.    If the shortcuts are configurable, then there's no point in having a 
  76.    standard because people can set it to however they want.  Programmers and 
  77.    users both would be changing them to their own preference, and no two
  78.  
  79.    systems would be the same.
  80.  
  81. The standard  would  be  a  way  of  distributing  a  STANDARD  shortcut
  82. configuration,  and my guess is it will resemble the de facto  standards
  83. pretty much so people won't change the very global shortcuts.
  84.  
  85. BTW,  we could easily distribute TWO standard configurations:  one  with
  86. the german  ^U/^W and  one with  the  Motif standard  and ^W  for  close
  87. window.   Perhaps  we  should  pipe  the  SHORTCUT.INF  through  the   C
  88. preprocessor first (like .Xdefaults) and have a #define GERMAN.
  89.  
  90. Once we've settled a syntax,   we can continue the shortcuts  discussion
  91. in that syntax,  which will avoid ambiguous proposals.
  92.  
  93. ---
  94.  
  95. andre:
  96.  
  97.    Oh, am I allowed to see what you have decided to do to my proposals at that
  98.    stage, then? That's very generous of you.
  99.  
  100. I agree,  it was a rather brute proposal of mine.  But then,  I tried to
  101. get one discussion off the list for a while.  I thought I'd noticed that
  102. people liked the .Xdefaults-like notation,  so I thought let's have a go
  103. at that.  By the time I wrote that I didn't know you were going to write
  104. a proposal the very same day.
  105.  
  106.    I think I've covered that already. What we could do is to allocate
  107.    blocks of numbers for very specific tasks, such as DTP, MIDI, etc.
  108.    Would that make you happier? (e.g. 1000+ for DTP-oriented tasks, 2000+
  109.    for MIDI, 3000+ for painting/photo/etc, 4000+ for Database, etc).  Again
  110.    I wanted to avoid making this too complex - if it's hell to work with, no
  111.    one will bother.
  112.  
  113. Who's talking  about  NUMBERS?  Who's making  things  complicated  here?
  114. Although I do agree that many people find files like .Xdefaults hard  to
  115. maintain.  But making it case-insensitive already helps a bunch.
  116.  
  117.    The whole *idea* was to generate a file along the lines of ASSIGN.SYS, but
  118.    with multi-language (optional) comments to allow users to change it if they
  119.    want - or, as others have said, just use an editor.
  120.  
  121. The idea of a file came shortly after I proposed a system-wide  manager.
  122. Sure,  a  file  seems  better,   but  why  ASSIGN.SYS  as  its  example?
  123. ASSIGN.SYS is one of the most horrific file format's I've ever seen.
  124.  
  125. I re-read your first proposal,  but I still don't see what the actual
  126. purpose of your codes is.  Do you have anything concrete in mind when
  127. you say (still Andre:)
  128.  
  129.    The code numbers at the start of  each line would be defined as  part
  130.    of our spec, and used by each  application to determine what type  of
  131.    command is being defined on each line.
  132.  
  133. ?
  134.  
  135. ---
  136.  
  137. Michel:
  138.  
  139.    standard includes things such as block marking, what order modifiers
  140.    should appear in menus, how dialog boxes should react to keys, and how
  141.    the cursor should react to keys.  These are not things that can be
  142.    controlled in the SHORTCUT.INF file.
  143.  
  144. I don't  see why  not.  Just  don't bind  keys to  MENU ITEMS,   but  to
  145. descriptions of ACTIONS instead.  Such  an action could be  'select-all'
  146. but it could equally well be 'delete-word'.
  147.  
  148. ---
  149.  
  150. Tim:
  151.  
  152.    If,
  153.    in order to support your standard, I have to go through a lot of work and 
  154.    headaches, I'm not going to support your standard.  I want to write a
  155.  
  156.    good piece of software and not sacrifice good functionality because I had 
  157.    to spend a lot of time dealing with unnecessary overhead.
  158.  
  159. Good point.  We should try and keep things simple.  The SHORTCUT.INF, if
  160. it is ever to come,  should be designed to be
  161.  
  162.    a) easy to edit
  163.    b) easy to parse,  with the sort of things a program uses it for in mind.
  164.  
  165. I am also slightly horrified  by the idea that I'd  have to match for  a
  166. descriptive string  for  EVERY MENU  ITEM  or EVERY  ACTION  my  program
  167. supports in order to process a line of the SHORTCUT.INF file...  This is
  168. where a KEYMGR.ACC could  come in handy as  an intermediate between  the
  169. SHORTCUT.INF file and the programmer.   A program would simply call  the
  170. manager with its name,   its application class and  a key.  The  manager
  171. would return a simple code  (perhaps a 'long ascii' cookie) the  program
  172. could easily work with.
  173.  
  174. Then again... if we  adopt the RSC  editing option,  I  find it  equally
  175. hard to search the  menu for shortcuts and  then store them  somewhere. 
  176. You can't search the menu for every single key...
  177.  
  178. ---
  179.  
  180. michel:
  181.  
  182.    Yes, I agree.  Since each application knows what it supports and what it
  183.    does nto, it should only use the keyboard shortcuts for the general codes
  184.    that it supports.
  185.  
  186. Then we should allow  multiple assignments to one  key in the  standard.
  187. Otherwise we'd  get a  standard full  of word  processor codes  such  as
  188. Italic and Delete Paragraph and programs in other classes wouldn't  have
  189. any room left for their specialities.
  190.  
  191. Maybe we should then split the shortcuts into a group of keys which have
  192. ONE meaning (such as close window, cycle, select all),  and a series  of
  193. keys for which the programmer can choose between a number of options (at
  194. most,  say,  3 per key,  which reasonably resemble eachother).
  195.  
  196. ---
  197.  
  198. michel:
  199.  
  200.    I agree; codes are the way to go.  Parsing text is also a problem because
  201.    the user might edit the file (perhaps changing words or changing the
  202.    case of the text) and mess everything up.  Numbers parsing is more
  203.    efficient anyway.
  204.  
  205. Parsing numbers may be more efficient  for a computer,  but not for  me!
  206. But if you feel so generous as to write the SHORTCUT.INF editor for  us,
  207. I won't complain.
  208.  
  209. ---
  210.  
  211. Tim